home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000472_connolly@pixel.convex.com _Thu Dec 10 04:02:16 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA01609; Thu, 10 Dec 92 04:02:16 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA09242; Thu, 10 Dec 1992 04:15:41 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA08563; Wed, 9 Dec 92 21:15:38 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA14084; Wed, 9 Dec 92 21:15:36 -0600
  10. Message-Id: <9212100315.AA14084@pixel.convex.com>
  11. Newsgroups: comp.infosystems.gopher
  12. Subject: Re: Gopher+ Considered Harmful
  13. To: www-talk@nxoc01.cern.ch
  14. References: <75220@apple.apple.COM>
  15. Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
  16. Date: Wed, 09 Dec 92 21:15:36 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19. In article <75220@apple.apple.COM> dell@Apple.COM (Thomas E. Dell) writes:
  20. [ an excellent assesment of Gopher and Gopher+ prototocls ...]
  21.  
  22. >Proposal:
  23. > 
  24. >  Draft a protocol modeled after ideas present in SMTP, NNTP, and
  25. >  FTP, with a few commands to support existing functionality.
  26.  
  27. The World-Wide Web project is also taking on the next major
  28. revision of their protocol. I have suggested to them that NNTP
  29. makes a good basis, and they were agreeable.
  30.  
  31. I sincerely hope that Gopher+ and HTTP2 (HyperText Transfer
  32. Protocol, version 2) merge into an NNTP-style protocol.
  33.  
  34. I suggest we even make it NNTP compatible, except that it
  35. would be stateless: the server processes one transaction and
  36. then terminates the connection. And in addtion to requesting
  37. articles by number or by ID, we would add the ability to
  38. request them by path, a quoted string.
  39.  
  40. For exmaple:
  41.  
  42.    S:      (listens at TCP port XXX)
  43.    C:      (requests connection on TCP port XXX)
  44.    S:      203 wombat NNTP++ server ready
  45.    C:      BODY "foo/bar/xxx.z"
  46.    S:      222 "foo/bar/xxx.z" article retrieved. body text follows
  47.            (body text here)
  48.        .
  49.    S:      400 service discontinued
  50.  
  51. We would use the MIME standard for multimedia. We could allow
  52. binary content-transfer-encoding on 8-bit clean connections, and
  53. thus avoid the bandwidth needed to encode raw data.
  54.  
  55.    S:      (listens at TCP port XXX)
  56.    C:      (requests connection on TCP port XXX)
  57.    S:      203 wombat NNTP++ server ready
  58.    C:      ARTICLE "foo/bar/xxx.z"
  59.    S:      224 "foo/bar/xxx.z" All of article follows
  60.    S:      (transmits article in RFC822 format, with a raw binary body:)
  61.         (... other headers)
  62.         Mime-Version: 1.0
  63.         Content-Type: image/gif
  64.         Content-Transfer-Encoding: binary
  65.         Content-Octets: 1274
  66.  
  67.         (1274 bytes of raw data here)
  68.  
  69.    S:      400 service discontinued
  70.  
  71. Seems like a good idea to me. What does anybody else think?
  72.  
  73. Dan
  74.